test___arguments_provided___cfg_time_start_trig___no_errors is failing because timestamp stays at HOST instead of I/O TIME. I suspect this is a simulated device issue, since I get the same behaviour in LabView. I don't have a physical device currently that supports time triggering that can prove my theory, so I will update this test case once I know if it's an expected behavior on simulated device or not.

test___arguments_provided___cfg_time_start_trig___no_errors is failing because timestamp stays at HOST instead of I/O TIME. I suspect this is a simulated device issue, since I get the same behaviour in LabView. I don't have a physical device currently that supports time triggering that can prove my theory, so I will update this test case once I know if it's an expected behavior on simulated device or not.

That doesn't surprise me, but I'm having trouble finding specific driver code that would do this. If you validate in LV, then that's good. Another thing to validate is use NI I/O Trace to ensure the settings going to the driver from Python are what you expect.

@zhindes Got my hands on a physical cdaq-9189, yes it is able to set timescale to I/O time.

This is the result of IO Trace on a simulated FIeldDAQ device in Labview

This is the result of IO Trace on simulated FieldDAQ in python

From both it seems that the value being passed into C API is correct (IODevice). Just that simulated devices seem to return HOST instead of IO Device.